I. Field of the Invention
The present invention relates to network management using the Simple Network Management Protocol (SNMP) and, more particularly, to a system and method for monitoring SNMP tables.
II. Background and Prior Art
Data communication has become a fundamental part of computing. World-wide networks gather data about such diverse subjects as atmospheric conditions, crop production, and airline traffic. These networks evolved as independent entities without the ability, or, until recently, the need, to interconnect with one another. New technologies, generically named "internetworking", have emerged making it possible to interconnect many disparate physical networks and make them function as a coordinated unit. Using internetworking technologies, a host, for example, on one network, may traverse multiple networks and communicate with another host on a different network.
The size of an "internet", or group of interconnected networks, can vary quite significantly. For instance, the resulting network may be enormously large, such as the nation-wide DARPA (Defense Advanced Research Projects Agency) /NSF (National Science Foundation) Internet which connects most major research institutions, including universities, corporate and government labs. Conversely, the network may be relatively small, comprising only a single corporation's individual local area networks (LANs).
No matter the size of the network, it is clear that the task of effectively managing the resulting interconnected network is quite important and has been given a great deal of attention in the networking community. In managing a network, a network manager must keep track of the devices on the networks, monitor the network's performance and load, and diagnose and correct any problems.
While products that manage homogeneous networks have been available, managing heterogeneous networks is more complex and, until recently, no generally accepted heterogeneous network management standard existed. The Simple Network Management Protocol (SNMP), which originated as a means for managing the TCP/IP (Transmission Control Protocol/Internet Protocol) and Ethernet networks, has broadened rapidly since its monitoring and control transactions are completely independent of TCP/IP and Ethernet.
Using SNMP, network administrators can address queries and commands to network nodes and devices. SNMP monitors network performance and status; controls operational parameters; and reports, analyzes and isolates faults. The protocol accomplishes these functions by transporting management information between "Managers" and "Agents".
SNMP defines the following three basic components:
1. An Agent, a component housed within a managed network device such as a host, gateway, or terminal server. Each Agent stores management data and responds to the Manager's requests for this data, and may send a "TRAP", a special unsolicited SNMP message, to the Manager after sensing a prespecified condition. PA1 2. A Manager, a component housed within a Network Management Station. The Manager queries/controls Agents using various SNMP commands. PA1 3. A Management Information Base (MIB), a managed object database, accessible to Agents and manipulated via SNMP for network management application.
To carry out the Agent's and Manager's duties, SNMP specifies five types of commands or verbs, called Protocol Data Units (PDUs): GetRequest, GetNextRequest, SetRequest, GetResponse and Trap. Agents inspect and retrieve the management data after receiving either a GetRequest or a GetNextRequest PDU from a Manager. Managers use GetRequest for retrieving single values of the managed objects. The GetNextRequest is issued by the Manager to begin a primitive block transfer and the Agent returns the selected data with a GetResponse verb. Managers use SetRequest commands for instructing Agents to alter MIB variables while Traps are unsolicited messages sent by Agents to Managers after sensing prespecified conditions.
SNMP managed objects are logically grouped. For example, MIB II, the current Internet standard MIB, defines the following logical groups: system, interfaces, at, ip, icmp, tcp, egp, transmission, and snmp. Some of these groups are optional and may or may not be present in an SNMP managed device, depending upon the device's capability, i.e., if a device is performing exterior gateway protocol (.egp) routing, the group must be present. Other, proprietary groups of objects can be created by following the proper registration scheme.
The Manager is charged with, among other things, monitoring network performance and status, controlling operational parameters, and reporting, analyzing and isolating faults in its managed domain. In order to effectively accomplish these functions, the Manager requires precise and timely data regarding the network and the nodes in the network.
FIG. 1 illustrates a simplified network having four interconnected nodes, Node 1, Node 2, Node 3 and Node 4. The nodes are logically interconnected by transmission groups (TGs). As can be seen, Node 1 is connected to Node 2 by TG A, Node 1 to Node 4 by TG E, and so forth. Each node is a managed network device in the SNMP sense and has an Agent for storing management data and for responding to the Manager, which is logically connected to each Agent. The management data in this case may include node characteristics, such as its name, type, uptime, level of service, etc., as well as TG characteristics, such as owner of the TG, destination of the TG, whether the particular TG is presently operational, etc. In this case, some of the node characteristics data are interrelated to some of the TG characteristics data. For instance, if a new node is added to the network, it would be reflected in the node characteristics data. Likewise, new TGs would be reflected in the TG characteristics data as any new TG connects to the node.
Using present management systems and methods, the Manager periodically polls its Agents using GetNextRequest PDUs for receiving the managed objects maintained by the Agents. For example, a Manager may need to provide a graphical user interface (GUI) depicting a network map. The Manager initially polls each Agent using GetNextRequest PDUs for retrieving each respective Agent's entire managed object table(s) until all of the data is retrieved for building the network map GUI. Subsequently, after some of the conditions may or may not have changed, the Manager repeats the process of polling the Agents to retrieve their respective entire managed object table(s) so that changed conditions may be noted. FIG. 2 illustrates the traditional table retrieval where the Manager issues a series of GetNextResponse commands to the Agent which responds with corresponding GetResponse messages along with the requested data. For example, when the Manager issues a GetNextRequest (Index=FIRST) PDU, the Agent responds with a GetResponse (Index=FIRST+1) PDU along with the requested record. This is process is repeated until an "End of Table" response is received by the Manager. After the Manager waits a predetermined time, it duplicates this process and again retrieves the entire managed object table(s).
Some of the managed objects are quite dynamic but there is no present mechanism for retrieving only the changed objects--rather each Agent's entire managed object table(s) must be retrieved forcing the Manager to sort through the relevant and irrelevant data. This strategy is deemed unacceptable from both a useability and a performance perspective as the overhead of re-processing the entire table(s) of thousands of entries severely impacts the performance of the network, Agent and Manager.
FIG. 3 illustrates a traditional method of receiving change/update notifications. This method of indicating to the Manager that a change has occurred in an Agent's managed object database is done by having the Agent issue an unsolicited Trap PDU with the changed data. This strategy is deemed unacceptable from a reliability perspective as an update may never reach the Manager--and/or cannot be controlled by the Manager.
Further, many times, groups of managed objects are interrelated so that, when an object in one group changes, one or more corresponding objects in another group may need to be subsequently changed. (The node and TG tables, each previously described, are an example of this situation.)
Clearly, these interrelated tables need to be in "sync" from the Manager's perspective, that is, the Manager needs to have the latest updates for each of the tables in order to have an accurate picture of the network. If the tables are not in sync, the Manager's network map depicted by the GUI could, for instance, show TGs extending into space having no destination nodes or, alternatively, could show nodes having no interconnecting TGs.
Presently, there is no mechanism for allowing the Manager to effectively maintain views of its tables which are consistent with those of the Agents.